I chose reactive (retry on the real allocation failure) over proactive (estimate the buffer size and compare against ggml_backend_buft_get_max_size()) deliberately: a size estimate is VAE-architecture-specific (peak activation differs across SD/SDXL/Flux/Wan/LTX VAEs), so a hardcoded bytes-per-pixel constant would be brittle

Wouldn't be possible to check with the real value, calculated from the graph before the allocation?

Good call — done (pushed just now).

Instead of retrying on failure, the AUTO path now measures the planned compute-buffer size up front with ggml_gallocr_reserve_n_size (no-alloc planning, zero allocation) and compares it to ggml_backend_buft_get_max_size() before allocating; if it won't fit, it goes straight to tiling — no bytes-per-pixel estimate. On CPU get_max_size() is SIZE_MAX, so it no-ops there.

I kept the original retry-on-empty as a backstop for a genuine runtime OOM (planned size fits the max, but the device is actually full). Net effect on the auto path: the backend no longer prints its raw "allocation failed" error — just an INFO line and the tiled decode.

Validated on an AMD Radeon 8060S iGPU (Krea Q4, 1024²): --vae-tiling auto now logs only the INFO "retrying with tiling" and completes; off still fails; on still tiles.

I think having a fallback to vae tiling is a much welcome addition, but I'm having some small issues with the user experience there. Modifying the syntax of --vae-tiling arg from a flag to a tistate option will break previously working commands, and I think we could implement the same feature without breakling anything.

For example we could add a --vae-tiling-auto flag.

Alternatively, set "auto" tiling as default and add something like a --no-auto-vae-tiling to disable it.

Thanks — agreed, changing --vae-tiling's syntax wasn't worth the breakage. Pushed a revision (your alternative B):

• --vae-tiling is back to the original boolean flag (force tiling on).
• The auto-fallback is now the default — it only tiles when an untiled decode would exceed the backend's max buffer size, so it's non-breaking and strictly safer for existing commands (an untiled decode that previously fit behaves identically; one that previously OOM'd now recovers).
• --no-vae-tiling-fallback disables it for the old hard-fail behavior.

Validated on an AMD Radeon 8060S iGPU (Krea Q4, 1024²): default auto-recovers (logs vae: untiled decode buffer exceeded the backend limit; retrying with tiling, exit 0); --no-vae-tiling-fallback fails (exit 1); --vae-tiling tiles from the start (exit 0).

FWIW this is part of my sweeping memory-management / lazy-loading changes in #1470 as well.

Thanks @pwilkin, good to know. This one's deliberately narrow — it's an OOM safety-net in the VAE decode path: when an untiled decode would exceed the backend's max buffer size, it automatically falls back to tiling instead of erroring out. So it should be complementary to the broader memory-management / lazy-loading in #1470 rather than overlapping it. Happy to rebase on top of #1470, or defer to it entirely if you and leejet would rather land the consolidated approach — whatever keeps things cleanest.

@leejet — before I make any code changes here, I'd like your call on direction, since @wbruna raised two API options and deferred to your preference:

1. auto-fallback API. Currently a tristate on the VAE-tiling flag (off / on / auto — where auto tiles only when an untiled VAE compute buffer would exceed the backend's max single-buffer size). @wbruna suggested a threshold override instead — -1 disable, 0 auto, > 0 a user-set byte limit — letting a user raise the cap on a capable device, lower it to save VRAM, or work around Vulkan's ~1 GB suballocation cap. He also floated an extra_tiling_args-style parameter. Keep auto/on/off, or move to the threshold override?

2. size measurement. @wbruna noted the proactive measurement may include the VAE weights alongside the compute buffer (~2112 MB vs ~1920 MB), though it's likely moot on Vulkan since ggml_backend_buft_get_max_size returns the 1 GB suballocation block there. Refine, or leave as-is?

I'll hold the implementation until you point a direction, then make the changes.

the more useful max_buffer_size doesn't seem to be accessible from the API 😕).

Actually, there is a way to access it: ggml_backend_vk_device_supports_op rejects any tensor larger than the max buffer size. The following attempt:

diff --git a/src/core/ggml_extend.hpp b/src/core/ggml_extend.hpp
index 4ebbc0a..2c14551 100644
--- a/src/core/ggml_extend.hpp
+++ b/src/core/ggml_extend.hpp
@@ -1922,6 +1922,21 @@ protected:
             // genuine runtime OOM (planned size <= max, but the device is full)
             // is NOT caught here -- it still surfaces from the real reserve
             // below, so the reactive fallback remains the backstop.
+            if (sd_backend_is(runtime_backend, "Vulkan")) {
+                size_t max_size = 0;
+                for (int i = 0; i < ggml_graph_n_nodes(gf); ++i) {
+                    ggml_tensor* op = ggml_graph_node(gf, i);
+                    max_size = std::max(ggml_nbytes(op), max_size);
+                    if (!ggml_backend_supports_op(runtime_backend, op)) {
+                        LOG_DEBUG("%s: untiled compute op size %.2f MB exceeds backend support; deferring to tiling",
+                                  get_desc().c_str(),
+                                  max_size / 1024.0 / 1024.0);
+                        compute_buffer_deferred_to_tiling = true;
+                        return false;
+                    }
+                }
+                LOG_DEBUG("%s: max op size = %.2f MB", get_desc().c_str(), max_size / 1024.0 / 1024.0);
+            } else {
             size_t max_size = ggml_backend_buft_get_max_size(buft);
             if (max_size > 0) {
                 ggml_gallocr* probe = ggml_gallocr_new(buft);
@@ -1937,6 +1952,7 @@ protected:
                     return false;
                 }
             }
+            }
         }
 
         compute_allocr = ggml_gallocr_new(buft);

worked perfectly with my card's 4GiB limit. With an SDXL 1024x960 gen, I've got:

[DEBUG] ggml_extend.hpp:1931 - vae: untiled compute op size 4320.00 MB exceeds backend support; deferring to tiling

while the slightly smaller 960x960 worked without tiling, despite the graph as a whole getting much larger than 4GiB:

[DEBUG] ggml_extend.hpp:1938 - vae: max op size = 4050.00 MB
[DEBUG] ggml_extend.hpp:1969 - vae compute buffer size: 9031.86 MB(VRAM)

Of course, that would assume that "unsupported" means "too large"; but a truly unsupported operation would end up failing in the same way as before.